Vary Header
Response header
HTTP Cacheのsecondary keyとするrequest headerを指定する
RFC7231 7.1.4
mdn
例
req headerを指定する
code:response
Vary: Accespt-Encoding
複数指定してもいい
code:response
Vary: Accept-Encoding, User-Agent
その場合はANDになる
完全一致
これは特殊
code:reponse
Vary: *
Cache-Control: no-storeとだいたい同じ意味になる
普通にCache-Control: no-storeを指定した方が良いので、ほぼこの書き方はしない
Fastlyの記事ではこの指定は使うな、と書いている
良くない例
Cache Hit Ratioの低下に繋がる
頻繁に変わる値を指定する
e.g. referer
注意点
同一のURLに対しては、必ず同一のvaryを指定する
/mrsekut-book-4297119250/191 (3.11.1 Vary)
#WIP
どういうものか?
CDNなどでcacheする際に、Method + URLをHTTP CacheのCache Keyとすることが多い
URLとMethodを見れば、返却されるresourceが一意に決定できることを意味する
MethodというのはPOSTとかGETとかmrsekut.icon
しかし、Method + URLでは一意に決まらないことがある
例えば、 Accept-Encodingを使って圧縮した場合など
clientによって解釈できる圧縮形式が異なるため、URLが同一でも異なる値を返しうる
client Aに対してはgzipで圧縮する
client Bに対しては生データを返す
ということが起きる
この時に、client Bに対して、gzipを返してもclient Bはこの形式を解釈できないかもしれない
この場合、Method + URLだけでは一意に値を決められないため、cacheが機能しない
ここで、cache keyに加えて、HTTP Cacheのsecondary keyを導入すれば良い
上記の例の場合、Method + URL + Accept-Encodingで指定された値を見れば一意にできる
このkeyを指定するのがVary Header
Vary Headerにはrequest headerのfield名を指定する
何を指定すべきか?
HTTP Cacheのsecondary key
#??
Varyってそんな使うの?
同じURLに対して、異なるresourceを返す、というのはそんなに起こるものなのか?
圧縮の例はわかるmrsekut.icon
いいね、とか、投稿に紐づくコメント、とかもそうか
pc/mobileの出し分けとかは、URL変えちゃったほうがシンプルになると思う
/hoge/pcとかhoge?device=pcみたいに
これはRESTful APIのEndpointの設計の話か?
同一URLにするなら、responseの型は完全に一致させないといけないわけで、色々制約が大きい気がするんだけどmrsekut.icon
Accept-Encodingを指定するときの工夫
/mrsekut-book-4297119250/409
Origin Headerを指定するときの工夫
/mrsekut-book-4297119250/412
Varyがあれば、
同じURLに対してコンテンツが変化しうる
ということを意味する
/mrsekut-book-4297119250/403 (5.10.1 ヒット率を上げる)
originによっては勝手にVaryをつけるサービスもある
例えば、S3
そのせいでcacheが変にならないか気に掛ける必要がある
https://www.fastly.com/blog/best-practices-using-vary-header